Method and system for controlling use of a dynamically linked software library

ABSTRACT

A method for authenticating a software library, including inserting an encrypted checksum into a software library, and in response to loading the software library calculating a checksum of the software library, requesting the encrypted checksum from the library, decrypting the encrypted checksum, and checking whether or not the decrypted checksum agrees with the calculated checksum. A system is also described and claimed.

CROSS REFERENCES TO RELATED APPLICATIONS

[0001] This application is a continuation-in-part of assignee's pendingapplication U.S. Ser. No. 09/774,936, filed on Jan. 29, 2001, entitled“Method and System for Copy Protection of Data Content,” which is acontinuation-in-part of U.S. Ser. No. 09/397,331, filed on Sep. 14,1999, entitled “Method and System for Copyright Protection of DigitalImages Transmitted over Networks,” which is a continuation-in-part ofU.S. Ser. No. 09/313,067, filed on May 17, 1999, entitled “Methods andApparatus for Preventing Reuse of Text, Images and Software Transmittedvia Networks.”, in each of which is incorporated by reference herein.

FIELD OF THE INVENTION

[0002] The present invention relates to copy protection of data content,including content that is displayed by a computer on a display device.

BACKGROUND OF THE INVENTION

[0003] Content protection systems often operate by encrypting protectedcontent on server computers, and by using special client viewers todecrypt the encrypted content on client computers. Such a client viewermay be designed as a dynamic link library (DLL) that loads into viewerapplications. Using such a DLL, application developers may design theirown application interfaces for accessing encrypted content.

[0004]FIG. 1 is a simplified block diagram of a prior art contentprotection system. A server computer 110 includes an encoder 120 forencrypting protected content. A client computer 130 includes a decoderDLL for decoding encrypted content it receives from server computer 110.A content viewer application 150 loads and runs decoder DLL 140 within auser interface for viewing the protected content.

[0005] Content viewer application 150 is intended to be a trustedapplication, having access permission to the protected content. However,although decoder DLL 140 is not published, it is nevertheless possiblefor a hacker to reverse engineer the application programming interface(API) for decoder DLL 140, and to program his own rogue viewerapplication to load and run decoder DLL 140.

[0006] The ability to develop a rogue application running decoder DLL140 defeats the purpose of a content protection system.

SUMMARY OF THE INVENTION

[0007] The present invention provides a method and system for a softwarelibrary, such as a dynamically linked library (DLL) to verify whether ornot an application loading it is a trusted application. Upondetermination that the application is trusted, the software library canrun normally. However, upon determination that the application is nottrusted, the software library refuses to load.

[0008] Using the present invention, content protection systems, such asthe system illustrated in FIG. 1, can ensure that rogue applications donot run DLLs required to decrypt encrypted content.

[0009] More generally, the present invention provides a method andsystem to verify that a software library or application is authentic. Ina preferred embodiment, the present invention, a checksum of anauthentic software library or application is embedded within the libraryor application, respectively. To prevent forgery, the embedded checksumis first encrypted, preferably using a private/public key encryption.That is, the checksum is encrypted using a private key that is notincluded within the software library or application, but the encryptedchecksum is decrypted using a public key. The encrypted checksum isembedded within the library or application.

[0010] To verify that a software library or application is authentic,one directly calculates its checksum, and compares the calculatedchecksum with the checksum embedded therewithin.

[0011] There is thus provided in accordance with a preferred embodimentof the present invention a method for authenticating a software library,including inserting an encrypted checksum into a software library, andin response to loading the software library calculating a checksum ofthe software library, requesting the encrypted checksum from thelibrary, decrypting the encrypted checksum, and checking whether or notthe decrypted checksum agrees with the calculated checksum.

[0012] There is further provided in accordance with a preferredembodiment of the present invention a method for controlling use of asoftware library, including identifying a caller application that iscalling a software library, calculating a checksum of the callerapplication, retrieving an encrypted checksum from the callerapplication, decrypting the encrypted checksum, and checking whether ornot the decrypted checksum agrees with the calculated checksum.

[0013] There is yet further provided in accordance with a preferredembodiment of the present invention a system for authenticating asoftware library, including a data processor inserting an encryptedchecksum into a software library, a checksum calculator calculating achecksum of the software library, an interface for obtaining theencrypted checksum from the library upon request, a decoder decryptingthe encrypted checksum, and a comparator determining whether or not thedecrypted checksum agrees with the calculated checksum.

[0014] There is additionally provided in accordance with a preferredembodiment of the present invention a system for controlling use of asoftware library, including a system processor identifying a callerapplication that is calling a software library, an interface forobtaining an encrypted checksum from the caller application, a decoderdecrypting the encrypted checksum, a checksum calculator calculating achecksum of the caller application; and a comparator determining whetheror not the decrypted checksum agrees with the calculated checksum.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The present invention will be more fully understood andappreciated from the following detailed description, taken inconjunction with the drawings in which:

[0016]FIG. 1 is a simplified block diagram of a prior art contentprotection system;

[0017]FIG. 2 is a simplified flowchart of a method for authenticating asoftware library, in accordance with a preferred embodiment of thepresent invention; and

[0018]FIG. 3 is a simplified block diagram of a system forauthenticating a software library, in accordance with a preferredembodiment of the present invention;

[0019]FIG. 4 is a simplified flowchart of a method for authenticating acalling application, in accordance with a preferred embodiment of thepresent invention; and

[0020]FIG. 5 is a simplified block diagram of a system forauthenticating a calling application, in accordance with a preferredembodiment of the present invention.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

[0021] The present invention provides a method and system forauthenticating a software library or application. In a preferredembodiment, the present invention calculates a checksum of an authenticsoftware library or application, and embeds the checksum within thelibrary or application, respectively. To prevent forgery, the checksumis first encrypted, preferably using a private/public key encryption,and the encrypted checksum is embedded within the library orapplication.

[0022] To verify whether or not the library or application is authentic,the present invention directly calculates the checksum of the library orapplication, respectively, and compares the calculated checksum with theembedded checksum. If they agree, then the library or application isauthentic. Otherwise, the library or application is not authentic.

[0023] An n-bit checksum of a sequence of bits is typically a module 2sum of the n-bit blocks within the sequence. More generally, an n-bitchecksum can be a function of the bits, such as a sum of differentmultiples of the bits where only the n least significant bits of thesummands are calculated. Checksums were originally used in data linkcontrol for error detection in packet transmission. A well-knownchecksum used in the prior art is a cyclic redundancy check (CRC32) bitsequence.

[0024] Preferably checksums used with the present invention are securechecksums, also referred to as one-way functions or cryptographicchecksums. Such checksums are characterized in that it iscomputationally infeasible to find a message having a given checksum, orto find two different messages that produce the same checksum. Anexample of such a checksum is the Secure Hash Algorithm, SHA-1, adescription of which is available on the Internet athttp://www.itl.nist.gov/fipspubs/fip180-1.htm.

[0025] Private/public key encryption is described in U.S. Pat. No.4,405,829 to Rivest et al.

[0026] Reference is now made to FIG. 2, which is a simplified flowchartof a method for authenticating a software library, in accordance with apreferred embodiment of the present invention. At step 205, a checksumfor an authentic software library, denoted CKSM1, is calculated. At step210 CKSM1 is encrypted, preferably using a private/public keyencryption. At step 215 the encrypted CKSM1 is inserted into thesoftware library. Steps 205, 210 and 215 are preferably performed by asoftware library authenticator. The result of these steps is embeddingof an encrypted CKSM1 into the authentic software library.

[0027] At step 220 a caller application, desiring to verify that asoftware library it uses is authentic, calculates its own checksum ofthe software library, denoted CKSM2. At step 225 the caller applicationrequests the encrypted CKSM1 from the software library, preferably usinga method of the library for retrieving the encrypted CKSM1. At step 230the caller application decrypts the encrypted CKSM1 it receives from thesoftware library, preferably using a public key. At step 235 the callerapplication determines whether or not CKSM1 equals CKSM2. If so, then atstep 240 the caller application concludes that the software library isauthentic and proceeds normally to use the library. Otherwise, at step245 the caller application concludes that the software library is notauthentic, and proceeds abnormally. Abnormal processing may includeaborting, for example.

[0028] Reference is now made to FIG. 3, which is a simplified blockdiagram of a system for authenticating a software library, in accordancewith a preferred embodiment of the present invention. Shown in FIG. 3 isan authentic software library 305 and a software library authenticator310. Authenticator 310 includes a data processor 315 that (i) calculatesa checksum of the software library, denoted CKSM1; (ii) encrypts thechecksum, preferably using a private/public key encryption; and (iii)embeds the encrypted checksum into the software library. After beingprocessing by authenticator 310, software library 320 is generated.Software library 320 includes the encrypted CKSM1. Software library 320also includes an interface for retrieving the encrypted CKSM1 therefrom.

[0029] A caller application 330 desires to verify whether or not asoftware library it loads is authentic. Caller application 330 includesan interface 335 for requesting the encrypted CKSM1 from softwarelibrary 320. Caller application 330 also includes its own checksumcalculator, for calculating a checksum, denoted CKSM2, directly fromsoftware library 320. A decoder 340 decrypts the encrypted CKSM1,preferably using a public key, and a comparator 345 checks whether ornot CKSM1 equals CKSM2. If so, then caller application 330 is assuredthat the software library it loads is authentic. Otherwise, callerapplication 330 has discovered that the software library it loads is notauthentic.

[0030] Several advantages of the present invention can be noted fromFIGS. 2 and 3. Use of a private/public key encryption ensures that onlythe creator of a software library, who knows the private key, is able tomake his software library authentic; for unless the private key isknown, CKSM1 cannot be encrypted. Moreover, the private key ispreferably not embedded within the software library, so it does notreside on computers other than those of the creator.

[0031] An important feature of the present invention is that the methodfor authenticating a software library, as illustrated in FIG. 2, may beused in an opposite embodiment to authenticate an application that callsthe software library. Using this opposite embodiment, a software librarycan refuse to load its interface unless the application calling it is atrusted application.

[0032] Reference is now made to FIG. 4, which is a simplified flowchartof a method for authenticating a calling application, in accordance witha preferred embodiment of the present invention. At step 405, a checksumfor a trusted caller application, denoted CKSM1, is calculated. At step410 CKSM1 is encrypted, preferably using a private/public keyencryption. At step 415 the encrypted CKSM1 is inserted into the trustedcaller application. Steps 405, 410 and 415 are preferably performed by atrusted caller application authenticator. The result of these steps isembedding of an encrypted CKSM1 into the trusted caller application.

[0033] At step 420, the software library, in response to being calledfor loading into a caller application, identifies the caller applicationfrom a system stack. Specifically, when the caller application calls oneof the functions within the software library, the called function canlook in the stack one layer up to find a pointer to the callerapplication.

[0034] At step 425 the software library, desiring to verify that thecaller application is trusted, calculates its own checksum of the callerapplication, denoted CKSM2. At step 430 the software library requeststhe encrypted CKSM1 from the caller application. At step 435 thesoftware library decrypts the encrypted CKSM1 it receives from thecaller application, preferably using a public key. At step 440 thesoftware library determines whether or not CKSM1 equals CKSM2. If so,then at step 445 the software concludes that the caller application istrusted, and proceeds to load its interface and run. Otherwise, at step450 the software library concludes that the caller application is nottrusted, and preferably refuses to load its interface.

[0035] Reference is now made to FIG. 5, which is a simplified blockdiagram of a system for authenticating a calling application, inaccordance with a preferred embodiment of the present invention. Shownin FIG. 5 is a trusted caller application 505 and a trusted callingapplication authenticator 510. Authenticator 510 includes a dataprocessor 515 that (i) calculates a checksum of the calling application,denoted CKSM1; (ii) encrypts the checksum, preferably using aprivate/public key encryption; and (iii) embeds the encrypted checksuminto the calling application. After being processing by authenticator510, calling application 520 is generated. Calling application 520includes the encrypted CKSM1. Calling application 520 also includes aninterface for retrieving the encrypted CKSM1 therefrom.

[0036] A software library 530 desires to verify whether or not a callerapplication loading it is trusted. Software library 530 includes aninterface 535 for requesting the encrypted CKSM1 from caller application520. Software library 530 also includes its own checksum calculator, forcalculating a checksum, denoted CKSM2, directly from caller application520. A decoder 540 decrypts the encrypted CKSM1, preferably using apublic key, and a comparator 545 checks whether or not CKSM1 equalsCKSM2. If so, then software library 530 is assured that the callerapplication loading it is trusted. Otherwise, software library 530 hasdiscovered that the caller application loading it is not trusted.

[0037] Implementation Details

[0038] Referring back to FIG. 3, checksum calculator 350 preferablyskips over the encrypted CKSM1 embedded within software library 320 whendetermining its checksum. Otherwise, the checksum calculated by checksumcalculator 350, based on software library 320, may not agree with thechecksum calculated by data processor 315, based on software library305. Additionally, there may be other portions where software libraries305 and 320 disagree, which preferably are also skipped by checksumcalculator 350.

[0039] In a preferred embodiment of the present invention, portions ofsoftware library 305 and software library 320 can be designated as “tobe skipped” when calculating checksums thereof. Such designation may beaccomplished by special bit patterns preceding and/or following thedesignated portions. Checksum calculator 350 and data processor 315 areprogrammed to skip over the designated portions when calculating theirchecksums.

[0040] In a first embodiment of the present invention, the special bitpatterns and encrypted CKSM1 are generated within software library 305and software library 320 by software array definitions such as:

[0041] char header[16];

[0042] char checksum[16];

[0043] char ender[16];

[0044] The above declarations are preferably included in the programthat generates software library 305. Each of the above three arrays canstore 128 bits. By filling special bits into the header and enderarrays, a checksum calculator can determine that it has to skip thethree arrays when calculating its checksum. Moreover, data processor 315can use the header and ender bits to locate a position in softwarelibrary 305 where the encrypted CKSM1 is to be embedded.

[0045] In a second embodiment of the present invention, the three arraysabove, header[ ], checksum[ ] and ender[ ], can be combined into asingle array char checksum[48];

[0046] In this second embodiment the first sixteen bytes of the arraychecksum[ ] are used as a header, and the last sixteen bytes of thearray checksum[ ] are used as an ender. This embodiment is preferredover the first embodiment described hereinabove, since some compilersmay not allocate contiguous memory locations for the three arraysheader[ ], checksum[ ] and ender[ ].

[0047] In a third embodiment of the present invention, the header bytesinclude a length for the checksum, in which case the ender bytes are notrequired. Alternatively, the ender bytes may include a length for thechecksum, in which case the header bytes are not required.

[0048] It is apparent to those skilled in the art that the specificlengths of sixteen bytes for a header, sixteen bytes for a checksum andsixteen bytes for an ender are not required, and other lengths may beused as well.

[0049] In a fourth embodiment of the present invention, the location ofthe checksum bytes is known, in which case both the header bytes and theender bytes are not required and can be dispensed with.

[0050] Without the ability to skip over portions of software library 305when calculating a checksum, the infamous circular “chicken and the egg”problem would arise, whereby the checksum of software library 205 cannotbe calculated until the encrypted checksum is known.

[0051] Additional Considerations

[0052] In reading the above description, persons skilled in the art willrealize that there are many apparent variations that can be applied tothe methods and systems described.

[0053] The encrypted checksum need not be embedded within the softwarelibrary or application, but can instead be included separately. Thusstep 215 of FIG. 2 and step 415 of FIG. 4 may be replaced withrespective alternative steps including the encrypted CKSM1 elsewhere.

[0054] In another variation, the checksum may be encrypted using asecret key, instead of a private key, and the secret key itself may beencrypted using the private key. The encrypted checksum and encryptedsecret key may be embedded within the software or included elsewhere.Decryption is performed by first decrypting the secret key using apublic key, and thereafter decrypting the checksum using the decryptedsecret key.

[0055] In yet another variation, the checksum may be known in advance.

[0056] The present invention may also be used to authenticate in-memoryversions of a software library; for example, to check whether or not anin-memory version has been patched in memory.

[0057] In another embodiment of the present invention, a protectedsoftware library may check itself before running, rather than beingchecked by a calling application.

[0058] The present invention may also be embodied such that multiplecustomers can run a client application loading a protected softwarelibrary, without the need to share a common customer key. Specifically,in this embodiment a checksum of the client application is encryptedmultiple times, each time using a different private/public keyencryption. Thus if a version of the client application is intended foruse by a select group of customers, each customer is given a differentkey, and a checksum of the client application is encrypted with each oftheir keys, obviating the need for them to share a common key. Moreover,in this embodiment a customer is dropped without affecting othercustomers, by simply removing the copy of the checksum encrypted for hisspecific key.

[0059] The present invention may also be used for authenticatingsoftware resources such as document, image files, audio files and videofiles.

[0060] In the foregoing specification, the invention has been describedwith reference to specific exemplary embodiments thereof. It will,however, be evident that various modifications and changes may be madeto the specific exemplary embodiments without departing from the broaderspirit and scope of the invention as set forth in the appended claims.Accordingly, the specification and drawings are to be regarded in anillustrative rather than a restrictive sense.

What is claimed is:
 1. A method for authenticating a software library,comprising: inserting an encrypted checksum into a software library; andin response to loading the software library: calculating a checksum ofthe software library; requesting the encrypted checksum from thelibrary; decrypting the encrypted checksum; and checking whether or notthe decrypted checksum agrees with the calculated checksum.
 2. Themethod of claim 1 wherein the software library performs normally if thedecrypted checksum agrees with the calculated checksum, and performsabnormally if the decrypted checksum does not agree with the calculatedchecksum.
 3. The method of claim 1 wherein the encrypted checksum isencrypted using a private key.
 4. The method of claim 1 wherein saiddecrypting uses a public key.
 5. The method of claim 1 wherein saidcalculating skips at least one portion of the software library incomputing the calculated checksum.
 6. The method of claim 5 wherein eachof the at least one portion of the software library is preceded by acharacteristic sequence of bits.
 7. The method of claim 5 wherein eachof the at least one portion of the software library is followed by acharacteristic sequence of bits.
 8. The method of claim 7 wherein eachof the at least one portion of the software library is also preceded bya characteristic sequence of bits.
 9. The method of claim 5 wherein thelocation of the at least one portion of the software library is known.10. The method of claim 1 wherein the software library is a dynamicallylinked library (DLL).
 11. The method of claim 10 wherein the DLL is usedto decode protected electronic content.
 12. The method of claim 1wherein said calculating, requesting, decrypting and checking areperformed by a caller application calling the software library.
 13. Themethod of claim 12 wherein the caller application is a document viewer.14. The method of claim 12 wherein the caller application is a webbrowser.
 15. The method of claim 12 wherein the caller application is amail client.
 16. The method of claim 12 wherein the caller applicationis an instant messenger.
 17. A method for controlling use of a softwarelibrary, comprising: identifying a caller application that is calling asoftware library; calculating a checksum of the caller application;retrieving an encrypted checksum from the caller application; decryptingthe encrypted checksum; and checking whether or not the decryptedchecksum agrees with the calculated checksum.
 18. The method of claim 17wherein the software library runs if the decrypted checksum agrees withthe calculated checksum, and aborts if the decrypted checksum does notagree with the calculated checksum.
 19. The method of claim 17 whereinthe encrypted checksum is encrypted using a private key.
 20. The methodof claim 17 wherein said decrypting uses a public key.
 21. The method ofclaim 17 wherein said calculating skips at least one portion of thecaller application in computing the calculated checksum.
 22. The methodof claim 21 wherein each of the at least one portion of the callerapplication is preceded by a characteristic sequence of bits.
 23. Themethod of claim 21 wherein each of the at least one portion of thecaller application is followed by a characteristic sequence of bits. 24.The method of claim 23 wherein each of the at least one portion of thecaller application is also preceded by a characteristic sequence ofbits.
 25. The method of claim 21 wherein the location of the at leastone portion of the caller application is known.
 26. The method of claim17 wherein the software library is a dynamically linked library (DLL).27. The method of claim 26 wherein the DLL is used to decode protectedelectronic content.
 28. The method of claim 17 wherein said calculating,retrieving, decrypting and checking are performed by the softwarelibrary.
 29. The method of claim 28 wherein the caller application is adocument viewer.
 30. The method of claim 28 wherein the callerapplication is a web browser.
 31. The method of claim 28 wherein thecaller application is a mail client.
 32. The method of claim 28 whereinthe caller application is an instant messenger.
 33. A system forauthenticating a software library, comprising: a data processorinserting an encrypted checksum into a software library; a checksumcalculator calculating a checksum of the software library; an interfacefor obtaining the encrypted checksum from the library upon request; adecoder decrypting the encrypted checksum; and a comparator determiningwhether or not the decrypted checksum agrees with the calculatedchecksum.
 34. The system of claim 33 wherein the software libraryperforms normally if the decrypted checksum agrees with the calculatedchecksum, and performs abnormally if the decrypted checksum does notagree with the calculated checksum.
 35. The system of claim 33 whereinthe encrypted checksum is encrypted using a private key.
 36. The systemof claim 33 wherein said decoder uses a public key.
 37. The system ofclaim 33 wherein said checksum calculator skips at least one portion ofthe software library in computing the calculated checksum.
 38. Thesystem of claim 37 wherein each of the at least one portion of thesoftware library is preceded by a characteristic sequence of bits. 39.The system of claim 37 wherein each of the at least one portion of thesoftware library is followed by a characteristic sequence of bits. 40.The system of claim 39 wherein each of the at least one portion of thesoftware library is also preceded by a characteristic sequence of bits.41. The system of claim 37 wherein the location of the at least oneportion of the software library is known.
 42. The system of claim 33wherein the software library is a dynamically linked library (DLL). 43.The system of claim 42 wherein the DLL is used to decode protectedelectronic content.
 44. The system of claim 33 further comprising acaller application including said checksum calculator, decoder andcomparator.
 45. The system of claim 44 wherein the caller application isa document viewer.
 46. The system of claim 44 wherein the callerapplication is a web browser.
 47. The system of claim 44 wherein thecaller application is a mail client.
 48. The system of claim 44 whereinthe caller application is an instant messenger.
 49. A system forcontrolling use of a software library, comprising: a system processoridentifying a caller application that is calling a software library; aninterface for obtaining an encrypted checksum from the callerapplication; a decoder decrypting the encrypted checksum; a checksumcalculator calculating a checksum of the caller application; and acomparator determining whether or not the decrypted checksum agrees withthe calculated checksum.
 50. The system of claim 49 wherein the softwarelibrary runs if the decrypted checksum agrees with the calculatedchecksum, and aborts if the decrypted checksum does not agree with thecalculated checksum.
 51. The system of claim 49 wherein the encryptedchecksum is encrypted using a private key.
 52. The system of claim 49wherein said decoder uses a public key.
 53. The system of claim 49wherein said checksum calculator skips at least one portion of thecaller application in computing the calculated checksum.
 54. The systemof claim 53 wherein each of the at least one portion of the callerapplication is preceded by a characteristic sequence of bits.
 55. Thesystem of claim 53 wherein each of the at least one portion of thecaller application is followed by a characteristic sequence of bits. 56.The system of claim 55 wherein each of the at least one portion of thecaller application is also preceded by a characteristic sequence ofbits.
 57. The system of claim 53 wherein the location of the at leastone portion of the caller application is known.
 58. The system of claim49 wherein the software library is a dynamically linked library (DLL).59. The system of claim 58 wherein the DLL is used to decode protectedelectronic content.
 60. The system of claim 49 wherein said checksumcalculator, decoder and comparator are included within the softwarelibrary.
 61. The system of claim 60 wherein the caller application is adocument viewer.
 62. The system of claim 60 wherein the callerapplication is a web browser.
 63. The system of claim 60 wherein thecaller application is a mail client.
 64. The system of claim 60 whereinthe caller application is an instant messenger.